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METHOD AND SYSTEM FOR SECURE CREDIT CARD TRANSACTIONS 
BACKGROUND OF THE INVENTION 

5 1. Technical Field: 

The present invention relates generally to an 
improved data processing system and in particular to a 
method and apparatus for managing data within a data 
processing system. More particularly, The present 
10 invention relates to the field of encryption technology. 
Still more particularly, the present invention relates to 
encryption key management for securing credit and debit 
card transactions. 

15 2, Description of Related Art: 

For years now, credit and debit cards have proven to 
be an efficient and convenient transaction medium for 
consumer to business transactions. Consumers have grown 
to rely heavily on these cards as a transaction medium in 
2 0 lieu of currency especially when carrying large sums of 

currency is either impractical or unsafe. Travelers have 
long understood the benefits for using credit and debit 
cards as currency for their convenience and security over 
physical currency . 

2 5 Some consumer transactions do not lend themselves 

well to physical currency, bank checks or bank drafts. 
It is difficult or impossible to conduct real time 
consumer transactions for tele-commerce businesses, e- 
commerce businesses and certain vending business 

3 0 applications using currency or checks. Merchants 

necessarily require a means for instantaneously debiting 
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a valid consumer account prior to completing the 
transaction.. On the other hand, consumers require real 
time responses from merchants and do not want to be 
troubled by carrying large sums of currency. Both the 
5 consumers and merchants suffer when currency, checks or 
other drafts are lost during transportation from the 
consumer to the merchant. Thus, many consumer /merchant 
transactions rely on credit and debit cards for 
completing the transaction. 

10 However, in many instances losses resulting from 

theft and fraud of credit and debit cards or their 
account information, are not recovered but rather shifted 
from the consumer and/or merchant to a financial 
institution that issued the card. Thus, while the 

15 consumer/merchant transactions seem more secure and less 
prone to fraud and theft, many times the losses are only 
transparent to the consumer and merchant utilizing credit 
and debit ca.rd technologies. In fact, the entire 
traditional and e-commerce markets are plagued with fraud 

2 0 and security holes that cannot be overcome by current 
tools and applications designed to tighten security 
around credit and debit cards. Examples of fraud range 
from stealirg physical cards, card numbers, or forging 
signatures to intercepting critical data related to the 

2 5 card. 

A typical example of credit card fraud involves a 
cashier x swiping' a customer's card in a valid card 
reader and then re-swiping the card in a clandestine card 
reader. By the time that issuing financial institutes 
30 realize that the card numbers are being used for illegal 
transactions, several thousand card numbers may have been 
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stolen. Tracking the source of such an operation is 
difficult, moreover identifying which cards used at the 
location that have been compromised is virtually 
impossible because of the extreme volume of financial 
5 institutions issuing credit cards. 

Another example of fraud involves e- commerce 
transactions. e-commerce facilities are not always 
secure from hackers . A hacker may attack the merchant 1 s 
server, proxy or website to gain credit card information. 

10 Once a facility is compromised, credit card numbers can 
be used by the hacker or others for fraudulent 
transactions. In one recent case, a website was 
compromised and numerous credit card numbers were posted 
on a public website. This required the financial 

15 institutions that issued the credit cards to invalidate 

those card numbers, stop/verify pending transactions, and 
issue new card numbers to their account holders. 

Although not fraud per se, another credit card 
related concern is the potential for privacy violations. 

2 0 One type of such violation is the practice of "customer 
profiling" . Customer profiling is a means for 
identifying potential new customers based upon predicting 
individual's future buying habits. These habits are 
developed into a "customer profile" by collecting and 

25 analyzing records of the customer's past credit card 

transactions. Customer profilers create such customer 
profiles and make the information available to merchants. 
The targeted customers may be subject to bombardment with 
junk mail circulars, telephone solicitation, unsolicited 

30 e-mail or the like. 
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The current customer-merchant -bank methodology lends 
itself to theft or misuse of credit card information. 
Therefore, it would be advantageous to reduce the ease at 
which credit and debit cards and their information is 
5 misappropriated or misused. 
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SUMMARY OF THE INVENTION 

The present invention provides a method and 
apparatus for securing credit and debit card 
5 transactions. The present invention employs a smart card 
as a credit card and contains memory and a 
microprocessor. A customer making a credit card 
transaction inserts their credit card into a card reader 
attached to the merchant's system e.g. cash register 

10 billing computer or the like. The card reader activates 
the customer's card and passes certain merchant 
information. After inputting the information, the 
merchant's system asks the customer's card for a "billing 
digest" . The billing digest is the result of a hashing 

15 function within the card operating upon the merchant 

information and the customer information (in combination 
the merchant information and customer information is 
referred to as transaction information) . The merchant 
information, including merchant identification number, 

20 merchant name, transaction type, amount, time/date, etc. 
while the customer information may include the customer's 
account number, name, etc. (the customer's master key is 
not transmitted to the merchant or the credit card 
issuer) . The billing digest is returned to the 

25 merchant's card reader that forwards it (and the 

transaction information) to the corresponding credit card 
agency or issuer, which maintains the customer's credit 
card account. In one embodiment, the transaction 
information is encrypted. The credit card issuer 

30 decrypts the information, if necessary, and looks up the 
customer's master key using the customer's account number 
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from the customer information. The credit card issuer 
then uses the information, including the customer's 
master key from the customer information, to verify the 
customer, merchant and transaction information by re- 
5 computing the billing digest and comparing this new value 
with the billing digest submitted by the merchant. This 
re-computed billing digest is termed an "authentication 
billing digest" . If the billing digest and 
authentication billing digest values are equivalent, then 

10 the customer's account is billed/credited the transaction 
amount, the merchant's account is billed/credited with 
the transaction amount, and an acceptance notification is 
returned to the merchant. If the billing digest values 
do not match, then no funds are transferred and a denial 

15 notification is returned to the merchant. Security is 

further enhanced by utilizing a unique reference for each 
transaction in the unique customer information used for 
creating the billing digest. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The novel features believed characteristic of the 
invention are set forth in the appended claims. The 
invention itself, however, as well as a preferred mode of 
use, further objectives and advantages thereof, will best 
be understood by reference to the following detailed 
description of an illustrative embodiment when read in 
conjunction with the accompanying drawings, wherein: 

Figure 1 is a diagram depicting the elements and 
connections between those elements as used in a 
commercial credit card transaction as may be employed in 
a preferred embodiment of the present invention; 

Figure 2 is a diagram depicting the function 
elements of a smart card in accordance with a preferred 
embodiment cf the present invention; 

Figures 3A and 3B are flowcharts depicting a process 
for creating a billing digest for conducting a secure 
credit card transaction in accordance with a preferred 
embodiment of the present invention; 

Figures 4A and 4B are flowcharts depicting a process 
for responding to a secure transaction, which includes a 
billing digest in accordance with a preferred embodiment 
of the present invention; 

Figure 5 is a flowchart depicting the processes for 
invoking the GetNextDigest ( ) function for creating the 
billing digest; 

Figures 6A and 6B are flowcharts depicting a process 
for creating a billing digest for conducting a secure 
credit card transaction, which cannot be tracked by a 
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profiling agency in accordance with a preferred 
embodiment of the present invention; and 

Figure*3 7A and 7B are flowcharts depicting a process 
for responding to a secure transaction, which includes a 
billing digest, which cannot be tracked by a profiling 
agency, in accordance with a preferred embodiment of the 
present invention . 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

With reference to Figure 1, a diagram depicting a 
commercial credit card transaction, as may be employed in 
5 a preferred embodiment of the present invention. 

Customers' Smart Card 100 is read by card terminal 120 
facilitating communication with merchant's system 130. 
Smart card 100 is a conventional smart card known in the 
industry. An example of such a card is the Cryptoflex 

10 card series, which utilizes DES, Triple-DES, and RSA 

algorithms, available from Schlumberger Ltd., 277 Park 
Avenue New York, NY 10172. In accordance with a prior 
art commercial transaction, card terminal 120 reads the 
customer credit card account information and passes that 

15 information to merchant system 130. Card terminal 120 
may be any commercially available terminal, such as the 
MagIC Range series of terminals available and trademarked 
by Schlumberger Ltd. Merchant system 130 then combines 
the customer account information with merchant 

20 transaction information (including time and date of the 
purchase, purchase amount, summary of the purchased 
items, the merchant's identification number, the credit 
card number and the identity of the credit card issuer) . 
Merchant's system 130 then transmits customer's credit 

25 card account information with the merchant transaction 
information to credit card issuer's system 140. The 
transaction information sent to the credit card issuer 
may or may not be conveyed over a secure transmission. 
If the transmission means is not secure, both the 

3 0 customer account information and the transaction 
information may be compromised. With the recent 
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proliferation of e-commerce transactions over the 
Internet, security is a prime concern for the customer, 
merchant and credit card issuer. In the prior art 
business transaction model, an unauthorized user can 
5 conduct e-commerce transactions with no more information 
than a customer's credit card number and expiration date. 

Credit card issuer's system 140 accesses customer 
and merchant databases 150 for customer and merchant 
information. Customer information comprises information 

10 about individual customers including account number, 
name, etc. while the merchant information comprises 
information about individual merchants including 
identification number, name, etc. in addition to 
transaction type, amount, time/date, etc. The 

15 combination of customer and merchant information will be 
referred to as transaction information and will be 
discussed in greater detail below. 

The credit card issuer evaluates such criteria as 
customer account limits, current customer account 

2 0 balance, transaction type, customer account type and 
merchant account validity prior to approving the 
transaction between the merchant and the customer. If 
the transaction would not violate any credit card issuer 
parameters, based on the current customer account 

25 criteria, then the transaction is approved. Once 

approved, the customer's account is debited/credited by 
the transaction amount. Simultaneously, the merchant's 
account is credited/debited by an amount equal to the 
transaction amount. A transaction confirmation is then 

30 sent from the credit card issuer's system 140 to 
merchant's system 13 0, along with the new account 
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balances for both the merchant's account and the 
customer's account. Upon receiving confirmation from the 
credit card issuer, the merchant usually prints out hard 
copies for itself and the customer, and then transmits 
5 the customer account balance information to card terminal 
120. From there, the account balance information stored 
on customer's smart card 100 is updated to reflect the 
transaction. 

Hughes and McCown disclose an encryption key 

10 management technique in U.S. Patent Application Number 
09/443,963, entitled "ENCRYPTION KEY MANAGEMENT SYSTEM 
USING MULTIPLE SMART CARDS", filed on November 19, 1999, 
attorney docket number 99-064-MIS. That application is 
incorporated by reference in it entirety. 

15 With reference to Figure 2, a diagram depicting the 

function elements of a smart card in accordance with a 
preferred embodiment of the present invention, smart card 
200 has three basic elements: smart card I/O 210 for 
communicating with a smart card terminal, onboard memory 

20 220 and processor 230 for processing information from 
smart card I/O 210 and onboard memory 220. Smart card 
2 00 may be any credit card containing memory and a 
microprocessor which conforms to the ISO 7816, ISO 14443, 
or similar series of standards. Onboard memory 220 

25 contains both data and executable routines and algorithms 
necessary for conducting commercial transactions. One 
such routine is a card security pin routine 226 used for 
preventing unauthorized possessors of smart card 2 00 from 
conducting commercial transactions. Card security pin 

30 routine 226 is a security layer which prompts the 

possessor of smart card 200 for a pin number prior to 
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making the functionality of smart card 200 available to 
the user. Once the smart card possessor enters a correct 
pin number, via a smart card terminal, the possessor has 
access to all data and functionality available on smart 
5 card 200. Another security routine available on smart 
card 200 is one or more hashing algorithms. These 
algorithms include HMAC (Hashing based Message 
Authentication Codes) , which is a mechanism for message 
authentication using cryptographic hash functions. HMAC 

10 can be used with any iterative cryptographic hash 

function, e.g.,SHA-l, in combination with a secret shared 
key. The Secure Hash Algorithm (SHA) , the algorithm 
specified in the Secure Hash Standard (SHS, FIPS PUB 180- 
1: Secure Hash Standard, April 1995), was developed by 

15 NIST. Here the HMAC-SHA-1 algorithms may be self 

executing applications or applets, or may merely be 
accessed by an application in response to a new billing 
digest request, GetNextDigest ( ) . 

A digest is the binary result of a hashing function, 

20 such as the HMAC-SHA-1 algorithm. A digest is computed 
by inputting a piece of data into a hashing function. 
Only hashes of equal inputs generate equal digests. 
Digests may be used to determine the authenticity of data 
from one instance to another. The billing digest 

25 returned in response to a new billing digest request is 
merely a digest generated from specific transaction 
information such as: transaction type, amount, time/date, 
merchant narre, merchant identification number, customer 
account number, customer name. This value is generated 

30 on the customer's smart card. With each request for a 
billing digest, a new 160-bit billing digest and a 
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corresponding variable N are returned to the merchant 
(this process will be discussed in detail below with 
respect to the flowcharts) . While the term "billing 
digest" is used herein, as a practical matter a billing 
5 digest will be requested for any customer transaction 
such as credit card charged purchases, account debited 
purchases, refunds and other customer transactions. 

In accordance with a preferred embodiment of the 
present invention, smart card 200 utilizes encryption 

10 variables for credit card account 222 in the HMAC-SHA-1 
process. Encryption variables for credit card account 
222 are but one of a plurality of sets of encryption 
variables for separate credit card accounts 223 and 224. 
Encryption variable for each credit card account 222, 

15 include a master key (KM) , smart card number (G) , credit 
card number (C) and a reference number (n) , which is 
incremented at each transaction. KM, C and n are 
instantiated from the issuer of the credit card account. 
Additionally, other encryption variables for a credit 

2 0 card account may include the credit card account issuers 

public key (KP) . Smart card 200 four encryption 
variables 222 comprise: 

1. A 256-bit Master Key (KM) that is set by the 
credit car issuer when the smart card is 

25 first initialized; 

2. A 16-byte key credit card number (C) that is 
set by the credit card issuer when the smart 
card is first initialized; 

3. A 5-byte reference number (n; initially set 

3 0 to 0) corresponding to each of the billing 

digests that it has generated (i.e., via a 
call to GetNextDigest () ) ; and 

4. A 32-bit smart card identifier number (G) 
which describes the smart card to which the 

35 master key has been issued, alternatively, G 
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may be a group number describing a set of 
smart cards using the same master key (KM) 
and credit card number (C) . 

5 The length of the values presented herein are 

representative of a preferred embodiment of the present 
invention, but in practice may consist of any bit length. 
The master key is generated by an off-board application 
for the sole purpose of creating these cards and then 

10 destroyed. A one-time key is used for generating KM and 
destroyed. The KM is written to encryption smart card 
200 when the smart card is initiated. KM must remain a 
secret because the key generation processes relies on 
three primary components: the range number (N) , which may 

15 be found, unencrypted, in the transmitted information; 
the public domain hashing algorithms; and KM. Of the 
three, KM is the only secret component which will not be 
transmitted. 

20 With respect to encryption variables 222, smart card 

number (G) is issued to the card or cards with the same 
KM. G can be any length, but a 4 -byte value has been 
implemented. Credit card number (C) is a unique credit 
card account designation, which is assigned to each 

25 credit card customer, or group of customers sharing the 
same account. C can be any length, but it is currently 
implemented as a 16-byte value. Each encryption smart 
card 200 implements a key range variable (N) , which is a 
concatenation of the card group (G) , the individual card 

30 number (C) , and the reference number (n) (of the form 

OxGGGGCCCCCCCCCCCCCCCCnnnnn) . For example, key card #1 
would have the range 0x0000123456789012345600000 - 
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0x00001234567890123456FFFFF and key card #2 would have 
the range 0x0001123456789012345600000 - 
0x0 00 14 12 34 5678 9 012 34 5 6FFFFF . 

Once initialized, C, G, and KM cannot be changed. 
5 After the customer's smart card generates each billing 
key (described in detail below), n is incremented by one. 
When n reaches the boundary of the reference values 
(e.g., OxFFFFF) , encryption smart card 200 can no longer 
be used for key generation. Up to 4 0 96 key generation 

10 cards may be created for a given KM and each card 
generates a unique set of keys. 

In reference to Figures 3A and 3B, a flowchart 
depicting a process for creating a billing digest for 
conducting a secure credit card transaction in accordance 

15 with a preferred embodiment of the present invention. 

The process begins with a customer's card being swiped in 
a merchant's card terminal (step 302). In practical 
application, the customer's smart card will actually be 
inserted in a smart card terminal during the transaction. 

2 0 The interface may provide the user with a keypad for 

entering a personal identification number (PIN) or 
password. Alternatively or in addition, the smart card 
itself may require a biometric input such as a 
fingerprint from the customer prior to authorizing the 
25 customer to use the functionality of the smart cart. 

Regardless of the type of interface, once a smart card is 
read, the merchant's card terminal authenticates itself 
to the customer's smart card by passing unique merchant 
information (M) to the customer's smart card (step 304) . 

3 0 The unique merchant information may include data such as 

a list of credit card issuers supported by the merchant, 
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a valid credit card issuer merchant number for each 
credit card supported by the merchant, the transaction 
number, which is specific for each credit card issuer 
supported by the merchant, the time/date of the 
5 transaction, the purchase amount and the identification 
of the product or service. Depending on the transaction 
type, security level or other transaction factors, the 
unique merchant information (M) may include other 
merchant data with which to authorize the merchant's card 

10 terminal to the customer's smart card. Next, the 

merchant's card terminal asks the customer's smart card 
for a billing digest (step 306) . 

The customer's smart card receives the unique 
merchant information (M) and the request for a billing 

15 digest, and compares the list of credit card issuers 
supported by the merchant with a list of credit card 
accounts resident on the smart card. The customer's 
smart card selects a credit card issuer to transact with 
either by matching the merchant's list with the 

20 customer's accounts or utilizing a preset credit card 
account selection variable or manual input by the 
customer to the card terminal interface (step 308) . Once 
a credit card issuer has been selected, the customer's 
smart card discards all data concerning other credit card 

25 issuers passed by the merchant. Once a credit card 
account has been selected, the smart card retrieves 
unique customer card values from the smart card memory 
(step 310) . The unique customer values include such 
variables as the customer credit card number (C) for the 

3 0 selected credit card account, smart card number (G) , a 

recurrent reference number (n) and a master key (KM) for 
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the selected credit card account. The customer credit 
card number (C) and the master key (KM) are provided to 
the customer's smart card by the credit card issuer at 
the time the card was issued or renewed. Additionally, 
5 the credit card issuer provides a range of reference 
numbers from which reference number (n) is iterated at 
each transaction. 

Once the customer's smart card has received the 
unique merchant information and retrieved the unique 

10 customer values, the customer's smart card concatenates 
the unique customer's values of customer credit card 
number (C) , smart card number (G) and the current 
referenced number (n) into a unique customer number (N) 
(step 312) . 

15 N = CGn 

Once a unique customer number (N) has been concatenated, 
the function GetNextDigest ( ) is called. Using 
GetNextDigest () , the customer's smart card prepares a 
billing digest using the unique merchant information (M) , 

2 0 the master key (KM) from the credit card issuer and the 

unique customer information (N) (step 314) . Smart card 
then increments the value of the current reference number 
(n) (step 316) . 

n = n + 1 

25 The customer's encryption smart card can issue a maximum 
number of billing digests equal to the maximum value of n 
(reference number) . However, n is an incremental value 
that may be initialized at any value less than its 
maximum value. Therefore, the actual number of 

3 0 encryption keys generated by a particular card may vary 

from one key to the maximum value of n number of billing 
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digest, depending on the initial value which n was set. 
Multiple cards using the same credit card account number 
may be identified by the unique smart card number (G) 
involved in the transactions. In another embodiment, 
5 reference range value might be set from 000 - 199 on one 
smart card for a particular account, while another card 
drawn to the same account might have reference range 
values set from 500 - 699. By setting unique ranges for 
individual smart cards under the same credit card 

10 account, credit card issuer is able to identify the 
unique smart card it is transaction with. 

The billing digest, the unique merchant information 
(M) and the unique customer information (N) are then 
passed to the merchant (step 318) . The merchant in turn 

15 transmits the billing digest, the unique merchant 

information (M) and the unique customer information (N) 
(the billing digest and transaction information) to the 
credit card issuer (step 320) . 

With reference Figures 4A and 4B, a flowchart 

2 0 depicting a process for responding to a secure 

transaction, which includes a billing digest, in 
accordance with a preferred embodiment of the present 
invention. The process begins with the credit card 
issuer receiving the secure credit card transaction from 

2 5 the merchant (step 402) . A secured credit card 

transaction includes the billing digest and transaction 
information (unique merchant information (M) and the 
unique customer information (N) ) , which was transmitted 
by the merchant. The credit card issuer uses a parsing 

3 0 credit card algorithm to parse the unique customer 

information (N) into the separate unique customer values 
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of the credit card number (C) , smart card number (G) and 
the current reference number (n) (step 404) . Next, the 
credit card issuer performs a security check on the 
transaction by comparing the current reference number (n) 
5 to all previous reference numbers used to conduct 

previous credit card transactions with the customer (step 
406) . All previous reference number values are stored in 
a database associated with the customer's credit card 
number (C) . The check is then made to determine whether 

10 the current reference number had been previously used 
(step 408) . If the credit card number had been 
previously used, the credit card issuer denies the 
transaction, alerts its internal security of the 
possibility of a fraud being perpetrated, and then 

15 returns a declination response to the merchant (step 

410) . The process of responding to a secure transaction 
ends without completing the transaction. 

Returning to step 408, if the credit card issuer 
determines that the current reference number (n) has not 

20 been previously used, the credit card issuer looks up the 
master key (KM) using the customer's credit card number 
(C) (step 412) . With the master key (KM) and the unique 
customer values, the credit card issuer then invokes 
GetNextDigest () . The GetNextKeyO digest function is a 

25 hashing algorithm of which are well known in the art. 

With the GetNextDigest () function, the credit card issuer 
prepares an authentication billing digest using unique 
merchant information (M) , the master key (KM) and unique 
customer information (step 414) . The authentication 

30 billing digest is exactly the same as the billing digest, 
with the exception that it is generated by the credit 
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card issuer and not in the customer's smart card. The 
credit card issuer then compares the authentication 
billing digest with the billing digest transmitted from 
the merchant (step 416) . If the authentication billing 
5 digest does not match the billing digest transmitted from 
the merchant, either an error has occurred during the 
transmission from the merchant or a fraud is being 
perpetrated. The credit card issuer then denies the 
transaction, alerts its internal security of the 

10 possibility of a fraud being perpetrated and returns a 
declination response and/or transmission error to the 
merchant (step 418) . The transaction between the 
merchant and the credit card issuer then ends. 

Returning to step 416, if the authentication billing 

15 digest generated by the credit card issuer exactly 

matches the billing digest transmitted from the merchant, 
the transaction can be completed. In that case, credit 
card issuer debits/credits the customer's account for the 
transaction amount, credits/debits the merchant's account 

2 0 for the transaction amount and returns a transaction 

confirmation to the merchant (step 420) . The process is 
then complete with respect to responding to a secure 
transaction. 

Of course, at this point, the customer will perform 
2 5 the obligatory signing of the credit card receipt and the 
transaction information may be written onto the memory of 
the customer's smart card. The transaction is complete 
with the customer retrieving the smart card. 

With reference to Figure 5, a flowchart depicting 
30 the process for invoking the GetNextDigest ( ) function for 
creating billing digest, calling the GetNextDigest () 
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function invokes a hashing algorithm. One of ordinary 
skill in the art would be familiar with a multitude of 
hashing algorithms either proprietary algorithms or 
algorithms in the public domain. The present invention 
5 will be described with respect to the HMAC-SHA-1 

algorithm, which is intended as an example only and not 
meant to limit the scope of the invention. The 
GetNextDigest () process begins with HMAC processing. 
Variables K_ipad and K_opad are created and a copy of the 

10 master key (KM) is copied on each (step 502) . For each 
byte in K__ipad, exclusive OR (XOR) 0X36 onto it. 
Similarly, for each byte in K_opad, exclusive OR (XOR) 
0x5c onto it (step 504) . Next, K_ipad is input into the 
SHA-1 hashing process (step 506) . The unique customer 

15 information (N) is retrieved from the transaction message 
(step 508) . The variable (N) is then added to the SHA-1 
process (step 510) . The master key value (KM) is then 
added to the SHA-1 process (step 512), and finally K_opad 
is added to the shay-1 hashing process (step 514) . The 

20 authentication billing digest is an output (step 516) . 
The process is now complete for invoking the 
GetNextDigest () function for creating billing digest. 

The above-described flowcharts disclose a secure 
credit card keying process in accordance with a preferred 

25 embodiment of the present invention. Creating a billing 
digest to accompany merchant and customer information 
secures the transaction process from unauthorized persons 
attempting to gain access to the customer's credit card 
number. In fact, customer, merchant and credit card 

3 0 information is commonly transmitted unencrypted. 

Therefore, customer profilers may conspire with the 



22 



Docket No. C0-022-MIS 

merchant to track all transactions occurring in the 
merchant's place of business. Even though the above- 
described processes greatly reduce the possibility of an 
unauthorized person conducting a transaction with a 
5 customer's credit card number, the customer and 

transaction information is still available to a customer 
profiling agency via the merchant. In accordance with 
another preferred embodiment of the present invention, 
the above -de scribed processes are modified by encrypting 

10 all pertinent information prior to passing information to 
the merchant. In so doing, the customer has complete 
anonymity from tracking or profiling. This functionality 
is added to the customer's smart card. 

In reference to Figures 6A and 6B, a flowchart 

15 depicting a process for creating a billing digest for 

conducting a secure credit card transaction which cannot 
be tracked by a profiling agency in accordance with a 
preferred embodiment of the present invention. The 
process depicted in Figures 6A and 6B is similar with the 

2 0 process described above with respect to Figures 3A and 

3B. Therefore, only the differences in the processes 
will be discussed in detail. The process begins with 
customer's smart card being swiped in the merchant's card 
terminal (step 602). The merchant's card terminal 
25 authenticates itself to the customer's smart card by 

passing unique customer information (M) to the smart card 
(step 604) . As discussed above, the unique merchant 
information (M) may include a list of credit card issuers 
supported by the merchant, a valid credit card issuer's 

3 0 merchant number for each credit card issuer supported by 

the merchant, the time/date of the transaction and the 
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transaction amount. The merchant's card terminal then 
asks the customer's smart card for a billing digest (step 
606) . The smart card then compares the list of credit 
card issuers supported by the merchant with the 
5 customer's credit card accounts and selects a credit card 
issuer to transact it (step 608). The customer's smart 
card will utilize only the information with respect to 
the selected credit card issuer. Smart card then 
retrieves unique customer values from its memory (step 

10 610) . Unique customer values include customer credit 
card number (C) , customer smart card number (G) and 
current reference number (n) , the master key (KM) for the 
selected credit card issuer. In contrast to the 
previously described embodiment, the smart card also 

15 retrieves a public key (KP) for the selected credit card 
issuer. Next, the smart card invokes the GetNextDigest ( ) 
function and concatenates the unique customer values into 
unique customer information (N) (step 612) . Smart card 
then prepares a billing digest using the unique merchant 

2 0 information (M) , master key (KM) and the unique customer 

information (N) (step 614) . Smart card then increments 
the value of the current reference number (n) (step 616) . 

n = n + 1 

Next, the smart card encrypts the unique merchant 
25 information (M) and the unique customer values (N) using 
the credit card issuers public key (KP) (step 618) . Once 
encrypted, all data passed to the merchants will be 
indecipherable. Smart card then passes the digest along 
with the encrypted unique merchant information (M) and 

3 0 the encrypted customer values (N) to the merchant (step 

620) . The merchant then transmits the billing digest, 
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encrypted unique merchant information (M) and the 
encrypted customer information (N) to the credit card 
issuer (step 622) . The process for creating a billing 
digest for conducting a secure credit card transaction is 
5 now complete;. 

With reference to Figures 7A and 7B, a flowchart 
depicting a process for responding to an secure 
transaction which includes a billing digest, which cannot 
be tracked by a profiling agency in accordance with a 

10 preferred embodiment of the present invention. The 

process depicted in Figures 7A and 7B is similar in many 
respects with that described above in 4A and 4B. The 
only differences in the two processes will be discussed 
in detail. The process begins with a credit card issuer 

15 receiving a billing digest encrypted unique merchant 

information (M) and encrypted unique customer information 
(N) from the merchant (step 702) . In contrast to the 
previous embodiment, the credit card issuer must decrypt 
unique merchant information (M) and unique customer 

20 information (N) prior to authenticating the information 
(step 704) . The credit card issuer decrypts the 
information using a private key. From here the process 
is identical with that described with respect to Figures 
4A and 4B. The credit card issuer uses a parsing 

2 5 algorithm to parse the unique customer information (N) 

back into unique customer values (step 706) . The current 
reference number (n) compared to all previous reference 
numbers used to conduct prior transactions on the 
customer's credit card number (C) (step 708) . A check is 

3 0 made to determine if the reference number (n) had been 

previously used (step 710) . If the number had been 
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previously used, the transaction is denied, internal 
security is alerted of the possibility of a fraud being 
perpetrated and a declination response is sent to the 
merchant (step 712) . The process then ends for that 
5 transaction. 

Returning to step 710, if the current reference 
number (n) had not been previously used, the credit card 
issuer uses customer's credit card number (C) to look up 
the master key (KM) issued to the customer (step 714) . 

10 Next, the GetNextDigest ( ) is invoked, which prepares an 
authentication billing digest using the unique merchant 
information (M) , the master key (KM) and the unique 
customer information (N) (step 716) . Next, the credit 
card issuer checks the authentication billing digest 

15 against the billing digest transmitted from the merchant 
(step 718) . If the authentication billing digest does 
not exactly match the billing digest transmitted from the 
merchant, the transmission is denied. The credit card 
issuer alerts its internal security of the possibility of 

2 0 a fraud and returns a declination response and/or 

transmission error to the merchant (step 720) . Returning 
to step 718, if the authentication billing digest matches 
exactly the billing digest transmitted from the merchant, 
the customer's account is debited/credited for the 
25 transaction amount and the merchant's account is 

credited/ debited for the transaction amount (step 722). 
The credit card issuer returns a transaction confirmation 
to the merchant, it is understood that the confirmation 
must not contain any of the sensitive information that 

3 0 was previously encrypted in the transmission from the 
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merchant which may identify the customer either by name 
or by credit card. The process ends. 

The description of the present invention has been 
presented for purposes of illustration and description, 
5 and is not intended to be exhaustive or limited to the 
invention in the form disclosed. Many modifications and 
variations will be apparent to those of ordinary skill in 
the art. For example, although the HMAC-SHA-1 hash 
process is illustrated, other hashing algorithms are 

10 common and may be used. Further, while the presently 
described mechanism of the present invention for 
encrypting the transmission between the merchant and the 
credit card issuer is a public/private encryption scheme, 
other encryption techniques are well known and wide 

15 spread in the industry. For example, the credit card 
issuer may utilize a private/private key encryption 
scheme. Still another modification of the present 
invention is for the merchant's machine to utilize the 
present process for hashing the transaction information. 

2 0 Additionally, the mechanism of the present invention also 

may be applied to transactions other than commercial 
credit card transactions. The preferred processes are 
easily adapted to any transaction in which a smart card 
is used to transmit sensitive information. Still further 
25 the transaction information may include any combination 
of information types from the customer and merchant with 
the exception of some private information, the master 
key, know only to the customer and the credit card 
issuer. However, the transaction information must 

3 0 provide the credit card issuer with a customer identifier 

for looking up the customer's account and master key, 
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and, of course, a merchant identifier to look up the 
merchant's account. The embodiment was chosen and 
described in order to best explain the principles of the 
invention, the practical application, and to enable 
5 others of ordinary skill in the art to understand the 
invention for various embodiments with various 
modifications as are suited to the particular use 
contemplated . 
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CLAIMS : 

What is claimed is: 

1 1. A method for securing a transaction comprising: 

2 receiving a request for a digest from a requestor; 

3 retrieving a master key; 

4 retrieving unique client information; 

5 creating the digest by hashing the unique client 

6 information and the master key; and 

7 returning the digest and the unique client 

8 information to the requestor, wherein the digest and the 

9 unique client information will be used for transacting 
10 with a third party. 

1 2. The method recited in claim 1 above, wherein the 

2 request further comprises unique requestor information 

3 and creating the digest further comprises hashing the 

4 unique requestor information. 

1 3. The method recited in claim 1 above, wherein the 

2 request includes unique merchant information which is 

3 used to access the master key. 

1 4. The method recited in claim 1 above, wherein the 

2 unique client information includes a reference number, 

3 the reference number being one of a plurality of 

4 reference numbers provided to the client by the third 

5 party. 

1 5. The method recited in claim 1 above, wherein 

2 creating the digest by hashing is performed by a smart 

3 card. 
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1 6. The method recited in claim 1 above further 

2 comprises encrypting the unique client information prior 

3 to retrieving the unique client information. 

1 7. The method recited in claim 1 above, wherein the 

2 transaction is a credit card transaction, the third party 

3 is a credit card issuer and the requestor is a merchant, 

4 further wherein the requestor information includes 

5 information describing at least one of a merchant 

6 identifier which is specific to the credit card issuer, a 

7 transaction identifier which is specific to the credit 

8 card issuer and purchase information which is specific to 

9 a purchase initiated by the client. 

1 8. A method for securing a transaction comprising: 

2 receiving, into a smart card, a data transmission 

3 from a merchant, wherein the data transmission includes 

4 unique merchant information, and a request for a billing 

5 digest; 

6 retrieving unique client information, from the smart 

7 card memory; 

8 retrieving a master key, the master key being known 

9 to a credit card issuer; 

10 creating the billing digest by hashing the unique 

11 client information, the master key and the unique 

12 merchant information onboard the smart card; and 

13 passing the billing digest, the unique merchant 

14 information and the unique client information to the 

15 requestor. 
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1 9. The method recited in claim 8 above, wherein the 

2 unique client information includes a reference number, 

3 the reference number being one of a plurality of 

4 reference numbers provided to the client by the credit 

5 card issuer. 

1 10. The method recited in claim 8 above further 

2 comprises encrypting the unique client information and 

3 the unique merchant information prior to passing the 

4 information to the merchant. 

1 11. A method for securing a transaction comprising: 

2 sending a data transmission to a client's smart 

3 card, wherein the data transmission includes unique 

4 merchant information and a request for a billing digest; 

5 receiving the billing digest, the unique merchant 

6 information and unique client information from the 

7 client's smart card, the billing digest being hashed from 

8 the unique merchant information, unique client 

9 information and secret information from the client's 

10 smart card; and 

11 transmitting the unique merchant information and 

12 unique client information from the client's smart card to 

13 a credit card issuer. 

1 12. The method recited in claim 11 above further 

2 comprises receiving a response from the credit card 

3 issuer. 

1 13 . A method for securing a transaction comprising: 
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2 receiving a transaction request from a requestor, 

3 wherein the request includes a digest and unique client 

4 information; 

5 accessing a master key based on the unique client 

6 information; 

7 creating an authorization digest by hashing the 

8 unique client information and the master key; 

9 comparing the authorization digest with the digest 

10 from the requestor; and 

11 returning a response to the requestor, the content 

12 of the response being based on an outcome of the 

13 comparison of the authorization digest with the digest 

14 from the requestor. 

1 14. The method recited in claim 13 above, wherein the 

2 request includes unique requestor information and 

3 creating the authorization digest further comprises 

4 hashing the unique requestor information. 

1 15. The method recited in claim 13 above, wherein the 

2 unique client information includes a reference number, 

3 the reference number being one of a plurality of 

4 reference numbers provided to the client by the third 

5 party. 

1 16. The method recited in claim 15 above further 

2 comprises: 

3 accessing all previously used reference numbers 

4 associated with the unique client information; 
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5 comparing the previously used reference numbers with 

6 the reference number contained in the unique client 

7 information; and 

8 returning a response to the requestor, the content 

9 of the response being based on the outcome of the 

10 comparison of the previously used reference numbers with 

11 the reference number contained in the unique client 

12 information. 

1 17. The method recited in claim 13 above, wherein 

2 creating the authentication digest by hashing is 

3 performed by a smart card. 
4 

5 18. The method recited in claim 13 above further 

6 comprises decrypting the unique client information prior 

7 accessing the master key. 

1 19. The method recited in claim 13 above, wherein the 

2 transaction is a credit card transaction and the 

3 requestor is a merchant, further wherein the requestor 

4 information includes information describing at least one 

5 of a merchant identifier which is specific to the credit 

6 card issuer, a transaction identifier which is specific 

7 to the credit card issuer and purchase information which 

8 is specific to a purchase initiated by the client. 

1 20. A method for securing a transaction comprising: 

2 generating a billing digest in a customer's smart 

3 card, the billing digest being hashed from merchant 

4 information, customer information and a master key; 
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5 creating an authentication digest by the credit card 

6 issuer, wherein the authentication digest is hashed from 

7 the merchant information, customer information and a 

8 master key associated with the customer information; 

9 comparing the authorization digest with the billing 

10 digest; and 

11 authorizing a transaction based on the comparison of 

12 the authorization digest with the billing digest. 

1 21. A methcd for securing a transaction comprising: 

2 indexing a master key to an account identifier for 

3 an account, wherein the account is between a customer and 

4 a financial institution; 

5 providing the master key to the financial 

6 institution and a smart card controlled by the customer; 

7 passing transaction data through a third party, 

8 wherein the transaction data includes at least the 

9 customer account identifier, third party information and 

10 a billing digest which is created from the customer 

11 account identifier, the third party information and the 

12 master key. 

1 22. A smart card for conducting secure transactions 

2 comprising: 

3 a input/output mechanism; 

4 a processor; and 

5 a memory containing: 

6 financial account information; 

7 a master key; 

8 functional hashing algorithm; 
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9 an executable application, for executing on the 

10 processor, for invoking the functional hashing 

11 algorithm, wherein the functional hashing algorithm 

12 creates a digest from the financial account 

13 information and the master key and further wherein 

14 the executable application transmits, via the 

15 input/output mechanism, the digest and the financial 

16 account information to a requestor. 

1 23. A system for conducting secure transactions 

2 comprising: 

3 a client smart card for creating a billing digest 

4 from a resident client information, a resident master key 

5 and imported merchant information; 

6 a merchant system for requesting the billing digest 

7 and for passing secure transaction information and the 

8 billing digest to a financial institution, wherein the 

9 transaction information comprises the client information, 

10 and the imported merchant information; and 

11 a financial institution for receiving the 

12 transaction information and billing digest and for 

13 authorizing a transaction by: 

14 accessing a master key based on the client 

15 information; 

16 creating an authorization digest from the 

17 master key, the client information and the merchant 

18 information; and 

19 comparing the authorization billing digest with 

20 the billing digest. 



1 
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2 receiving means for receiving a request for a digest 

3 from a requestor; 

4 retrieving means for retrieving a master key; 

5 retrieving means for retrieving unique client 

6 information; 

7 creating means for creating the digest by hashing 

8 the unique client information and the master key; and 

9 returning means for returning the digest and the 

10 unique client information to the requestor, wherein the 

11 digest and the unique client information will be used for 

12 transacting with a third party. 

1 25. The system recited in claim 24 above, wherein the 

2 request further comprises unique requestor information 

3 and creating- the digest further comprises hashing the 

4 unique requestor information. 

1 26. The system recited in claim 24 above, wherein the 

2 request includes unique merchant information which is 

3 used to access the master key. 

1 27. The system recited in claim 24 above, wherein the 

2 unique client information includes a reference number, 

3 the reference number being one of a plurality of 

4 reference numbers provided to the client by the third 

5 party. 

1 28. The system recited in claim 24 above, wherein the 

2 creating means for creating the digest by hashing is 

3 performed by a smart card. 
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1 29. The system recited in claim 24 above further 

2 comprises encrypting means for encrypting the unique 

3 client information prior to returning the unique client 

4 information. 

1 30. The system recited in claim 24 above, wherein the 

2 transaction is a credit card transaction, the third party 

3 is a credit card issuer and the requestor is a merchant, 

4 further wherein the requestor information includes 

5 information describing at least one of a merchant 

6 identifier which is specific to the credit card issuer, a 

7 transaction identifier which is specific to the credit 

8 card issuer and transaction data which is specific to a 

9 transaction initiated by the client. 

1 31. The system recited in claim 24 above further 

2 comprises: 

3 fingerprint reading and identification means for 

4 reading a fingerprint and authorizing a client based on 

5 an identity of a client's fingerprint. 

1 32. A system for securing a transaction comprising: 

2 receiving means for receiving a transaction request 

3 from a requestor, wherein the request includes a digest 

4 and unique client information; 

5 accessing means for accessing a master key based on 

6 the unique client information; 

7 creating means for creating an authorization digest 

8 by hashing the unique client information and the master 

9 key; 
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10 comparing means for comparing the authorization 

11 digest with the digest from the requestor; and 

12 returning means for returning a response to the 

13 requestor, the content of the response being based on the 

14 outcome of the comparison of the authorization digest 

15 with the digest from the requestor. 

1 33. The system recited in claim 32 above, wherein the 

2 request includes unique requestor information and 

3 creating the authorization digest further comprises 

4 hashing the unique requestor information. 

1 34. The system recited in claim 32 above, wherein the 

2 unique client information includes a reference number, 

3 the reference number being one of a plurality of 

4 reference numbers provided to the client by the third 

5 party. 

1 35. The system recited in claim 34 above further 

2 comprises: 

3 accessing means for accessing all previously used 

4 reference numbers associated with the unique client 

5 information; 

6 comparing means for comparing the previously used 

7 reference numbers with the reference number contained in 

8 the unique client information; and 

9 returning means for returning a response to the 

10 requestor, the content of the response being based on the 

11 outcome of the comparison of the previously used 

12 reference numbers with the reference number contained in 

13 the unique client information. 
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1 36. The system recited in claim 32 above, wherein 

2 creating the authentication digest by hashing is 

3 performed by a smart card. 

1 37. The system recited in claim 32 above further 

2 comprises decrypting the unique client information prior 

3 accessing the master key. 

1 38. The system recited in claim 32 above, wherein the 

2 transaction is a credit card transaction, the third party 

3 is a credit card issuer and the requestor is a merchant, 

4 further wherein the requestor information includes 

5 information describing at least one of a merchant 

6 identifier which is specific to the credit card issuer, a 

7 transaction identifier which is specific to the credit 

8 card issuer and transaction data which is specific to a 

9 transaction initiated by the client. 

1 39. A computer program product for securing a 

2 transaction embodied on a computer readable medium 

3 comprising: 

4 receiving instructions for receiving a request for a 

5 digest from a requestor; 

6 retrieving instructions for retrieving a master key; 

7 retrieving instructions for retrieving unique client 

8 information; 

9 creating instructions for creating the digest by 

10 hashing the unique client information and the master key; 

11 and 

12 returning instructions for returning the digest and 

13 the unique client information to the requestor, wherein 
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14 the digest and the unique client information will be used 

15 for transacting with a third party. 

1 40. A computer program product for securing a 

2 transaction embodied on a computer readable medium 

3 comprising: 

4 receiving instructions for receiving, into a smart 

5 card, a data transmission from a merchant, wherein the 

6 data transmission includes unique merchant information, 

7 and a request for a billing digest; 

8 retrieving instructions for retrieving unique client 

9 information, from the smart card memory; 

10 retrieving instructions for retrieving a master key, 

11 the master key being known to a credit card issuer; 

12 creating instructions for creating the billing 

13 digest by hashing the unique client information, the 

14 master key and the unique merchant information onboard 

15 the smart card; and 

16 passing instructions for passing the billing digest, 

17 the unique merchant information and the unique client 

18 information to the requestor. 
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ABSTRACT OF THE DISCLOSURE 
METHOD AND SYSTEM FOR SECURE CREDIT CARD TRANSACTIONS 

5 A customer making a credit card transaction inserts 

their smart card into a card reader attached to the 
merchant's system. The card reader activates the 
customer's card and passes certain merchant information. 
The merchant's system then requests a "billing digest" 

10 from the customer's card. The billing digest is returned 
to the merchant's card reader that forwards it (and the 
transaction information which includes customer 
information and merchant information) to the 
corresponding credit card issuer, which maintains the 

15 customer's credit card account. In one embodiment, the 
customer information and the merchant information are 
encrypted. Upon receiving the billing digest, 
transaction information is decrypted if necessary and the 
credit card issuer looks up the customer's master key 

2 0 using the customer's account number. The credit card 

issuer then uses the transaction information to re- 
compute the billing digest (an authentication billing 
digest) and compares this new value with the billing 
digest submitted by the merchant. If authentic, the 
25 billing digest and authentication billing digest values 
are equivalent, then funds are transferred and an 
acceptance notification is returned to the merchant. If 
not authentic, a denial notification is returned to the 
merchant. Security is further enhanced by utilizing a 

3 0 unique reference for each transaction in the unique 

customer information used for creating the billing 
digest . 
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Begin 



Customer's Smart Card Swiped In 
Merchant's Card Reader 
302 
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Merchant's: Reader Authenticates Itself To The Smart Card By Passing Unique 

Merchant Information (M) To The Smart Card, Including: 
. A List Of Credit Card Issuers Supported By The Merchant; 
. A Valid Credit Card Issuer Merchant Number, For 

Each Credit Card Issuer Supported By The Merchant; 
. A Transaction Number, For Each Credit Card Issuer 

Supported By The Merchant; 
. Time/Dste Of Transaction; And 
. The Purchase Amount. 
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Merchant's Reader Asks The Smart Card For A Billing Digest 
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The Smart Card Compares The List Of Credit Card Issuers Supported By The Merchant 
Vith The Customer's Credit Card Accounts And Selects A Credit Card Issuer To Transact 
With (All Non-Selected Credit Card Issuer Information Is Discarded By The Smart Card) 

308 
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The Smart Card Retrieves Unique Customer Values Including: 

1 . The Customer's Credit Card Number (C), For The Selected Credit Card Account 

2. The Smart Card Number (G); 

3. The Current Reference Number (n); And 

4. Master Key ( KM) For The Selected Credit Card Account. 
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The Smart Card Concatenates Unique Customer Values, 
Customer Credit Card Number (C), The Smart Card Number (G) 
And The Current Reference Number (n) Into Unique Customer 
Information (N) 
312 



Invoke GetNextDigestQ 



The Smart Card Prepares A Billing Digest Using 
The' Unique Merchant Information (M), A Master Key From The 
Credit Card Issuer (KM) And Unique Customer Information (N) 
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The Smart Card Sets The Value Of Current Reference Number (n): 

n = n + 1 
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The Digest, Unique Merchant Information (M) And Unique 
Customer Information (N) Are Passed To The Merchant 
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Merchant Transmits Billing Digest, Unique Merchant Information 
(M) And Unique Customer Information (N) To The Credit Card 

Issuer 
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Begin 



Credit Card Issuer Receives Billing Digest, Unique Merchant Information 
(M) And Unique Customer Information (N) From The Merchant 

402 



Credit Card Issuer Uses Parsing Algorithm To Parse The Unique 
Customer Information (N) Into The Unique Customer Values: 

1 . The Customer's Credit Card Number (C); 

2. The Smart Card Number (G); 

3. The Current Reference Number (n). 



Current Reference Number (n) Is Compared To All Previous 
Reference Numbers Used To Conduct Previous Transactions 
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Using The Customer's Credit Card Number (C), The Credit Card 
Issuer Looks Up The Master Key (KM) Issued To The Customer 
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I 

Invoke GetNextDigestQ 

The Credit Card Issuer Prepares An Authentication Billing Digest 
Using The Unique Merchant Information (M), The Master Key 
(KM) And Unique Customer Information 
414 




Debit Customer's Account For The Purchase Amount, Credits 
Merchant's Account For The Purchase Amount And Return 
Transaction Confirmation To The Merchant 
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Deny Transaction, Alert Security Of 
A Possible Fraud Being Perpetrated 
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Using The Customer's Credit Card Number (C), The Credit Card 
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DECLARATION AND POWER OF ATTORNEY 
FOR PATENT APPLICATION 

As a below named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below next 
to my name; 

I believe I am the original, first and sole inventor (if only one name is 
listed below) or an original, first and joint inventor (if plural names are 
listed below) of the subject matter which is claimed and for which a patent is 
sought on the invention entitled 

METHOD AND SYSTEM FOR SECURE CREDIT CARD TRANSACTIONS 

the specification of which (check one) 
X is attached hereto. 

was filed on 

as Application Serial No. 

and was amended o.i 

(if applicable) 

I hereby state that I have reviewed and understand the contents of the above- 
identified specification, including the claims, as amended by any amendment 
referred to above . 

I acknowledge the duty to disclose information which is material to the 
patentability of this application in accordance with Title 37, Code of Federal 
Regulations, §1.56. 

I hereby claim foreign priority benefits under Title 35, United States Code, §119 
of any foreign application (s) for patent or inventor's certificate listed below 
and have also identified below any foreign application for patent or inventor's 
certificate having a filing date before that of the application on which 
priority is claimed: 

Prior Foreign Application (s) : Priority Claimed 

Yes No 

(Number) (Country) (Day /Month/ Year) 

I hereby claim the benefit under Title 35, United States Code, §120 of any United 
States application (s) listed below and, insofar as the subject matter of each of 
the claims of this application is not disclosed in the prior United States 
application in the manner provided by the first paragraph of Title 35, United 
States Code, §112, I acknowledge the duty to disclose information material to 
the patentability of this application as defined in Title 37, Code of Federal 
Regulations, §1.56 which occurred between the filing date of the prior 
application and the national or PCT international filing date of this applic- 
ation: 
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(Filing Date) 
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I hereby declare that all statements made herein of my own knowledge are true and 
that all statements made on information and belief are believed to be true; and 
further that these statements were made with the knowledge that willful false 
statements and the like so made are punishable by fine or imprisonment, or both, 
under Section 1001 of Title 18 of the United States Code and that such willful 
false statements may jeopardize the validity of the application or any patent 
issued thereon. 

POWER OF ATTORNEY: As a named inventor, I hereby appoint the following attorneys 
and/or agents to prosecute this application and transact all business in the 
Patent and Trademark Office connected therewith. 

Wayne P. Bailey, Reg. No. 34,289; Timothy R. Schulte, Reg. No. 29,013; Duke W. 
Yee, Reg. No. 34,285; Colin P. Cahoon, Reg. No. 38,836; Rudolph J. Buchel, Reg. 
No. 43,448; Stephen R. Loe, Reg. No. 43,757; Stephen J. Walder, Jr., Reg. No. 
41,534; Charles D. Stepps, Reg. No. 45,880; and Stephen R. Tkacs, Reg. No. P- 
46,430. 

Send correspondence to: Wayne P. Bailey, Storage Technology Corporation, One 
StorageTek Drive, Louisville, Colorado 80028-4309, and direct all telephone calls 
to Wayne P. Bailey, (303) 673-8223. 
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